Prefer the syncing version's own release as scan base - #134

The CLI picks its scan base by walking recent releases and taking the first one whose commit SHA exists in the repo's history. When more than one release is open on the same branch, that first match is not always the release being synced — for example a patch release that just completed can rank ahead of a long-running 2.0.0 train.

Before — syncing 2.0.0 (last synced at abc1234) while 1.4.2 ships from the same branch:

linear-release sync --release-version 2.0.0
# base = 1.4.2's commit → wrong scan range: issues land on the
# wrong release, or get scanned twice

After — a sync that names a version resumes that version's own release:

linear-release sync --release-version 2.0.0
# base = abc1234, 2.0.0's own last-synced commit

If no candidate matches the version — first sync of a new release, or its SHA is not in this repo's history — the existing walk runs unchanged. Cross-branch behavior (scenarios A–F) is untouched.